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TASK  AND  DRIVERS 


Reinventing  the  process  by  which  military  needs 
are  transformed  into  combatants  and  warfighting 
systems  is  a  task  of  great  moment  for  the  Navy.  This 
report  considers  a  reinvention  effort  driven  by  three 
factors: 

•  Making  sure  the  design  process  is  driven  by  what 
the  warfighters  (mission  teams)  must  do  -  that  is, 
put  ordnance  on  target; 

•  Adopting  a  “system  of  systems”  approach  to  inte¬ 
gration  so  that  a  unity  of  effort  can  be  maintained 
across  all  parts  of  the  ship,  from  keel  to  masthead; 

•  Making  sure  that  capable  ships  are  also  afford¬ 
able  through  continual  improvement  of  acquisition 
practices. 

These  drivers,  together  with  the  leadership  nec¬ 
essary  to  build  a  culture  of  teamwork,  constitute  the 
elements  of  a  framework  for  reinvention. 

In  this  section  of  the  report  we  outline  the  total 
ship  system  engineering  framework  and  the  status 
of  efforts  to  reduce  it  to  practice.  The  next  section 
reviews  the  traditional  approach  to  total  ship  engi¬ 
neering,  its  origin  and  evolution,  and  the  underlying 
concept  of  organization. The  third  section  considers 
implications  of  the  new  framework  for  ship  design 
and  engineering  activities,  while  the  last  section 
envisions  how  ship  characteristics  may  be  changed. 


Mission  Teams 

System  of  Systems 

Acquisition  Process 
Improvement 


THREE  FACTORS 


“The  Gang” 

A  group  of  key  Navy  acquisition  executives 
served  as  champions  for  this  effort.  The  activities 
shown  in  the  figure  were  the  main  contributors,  but 
others  took  part  at  times.  This  group,  often  called 
the  “Gang  of  Six,”  provided  strong  support  to  the  idea 
of  building  a  culture  of  teamwork  that  overcomes 
the  stovepiping  tendencies  of  the  past. 

Several  related  efforts  must  also  be  acknowl¬ 
edged.  Substantial  help  was  provided  by  the  RDT&E 
Division  (NRaD)  of  the  Naval  Command,  Control, 
Communications  and  Ocean  Surveillance  Center. 
The  Training  Systems  Division  of  the  Naval  Air  War¬ 
fare  Center,  the  Naval  Postgraduate  School,  and 
other  divisions  of  the  Naval  Surface  Warfare  Center 
(NSWC)  have  also  participated  in  the  effort. 

What  Mission  Teams  Must  Do 

We  can  think  of  ships  in  terms  of  the  mission 
teams  that  they  carry  to  the  operating  area,  where 
the  teams  may  be  called  upon  to  maintain  presence 
or  to  deliver  high-tech  firepower  against  an  adver¬ 
sary.  No  purpose  is  more  important  in  total  ship 
system  engineering  than  to  build  ships  that  can  pro¬ 
vide  what  the  warfighters  need. 

To  support  multiple  mission  teams  in  forward 
operating  areas,  ships  must  be  very  flexible,  capable 
of  tailoring  basic  capabilities  to  the  designated  mis¬ 
sion  tasks  and  operating  environments.  Teams  will 
have  to  deal  with  multiwarfare  threats,  in  heavy  clut¬ 
ter.  Uncertainty  about  roles  and  missions  is  charac¬ 
teristic  of  regional  conflict  situations,  and  the  rules 
of  engagement  are  often  complex.  Navy  and  Ma¬ 
rine  Corps  mission  teams  will  operate  as  integral 
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Multiple  Mission  Teams 

•  Forward  Presence  &  Readiness  External 

•  Directing  High-Tech  Firepower  Environment 


^  Tailored 
Mission  Capability 


O 

Easy  Upgrade 


Interoperability 


Multiwarfare  Threats 
Uncertain  Roles  &  Tasks 
Joint  &  Combined  Ops 
•  Emerging  Technology 


SUPPORTING  MISSION  TEAMS 


parts  of  joint  and  combined  forces.  (Because 
stovepiping  concerns  increase  with  the  level  of  force 
integration,  this  alone  warrants  an  effort  to  reinvent 
the  process  by  which  requirements  are  transformed 
into  ships.)  Due  to  the  pace  of  technological 
progress,  the  ongoing  “revolution  in  military  affairs,” 
and  the  importance  of  open  systems  for  affordability, 
ease  of  upgrade  must  also  be  emphasized. 


the  figure  suggests,  a  ship  is 
a  composite  of  many  indi¬ 
vidual  systems,  each  devel¬ 
oped  with  minimal  coordina¬ 
tion.  In  the  existing  acquisition 
culture,  systems  (a)  tend  to 
mirror  how  we  are  organized, 
(b)  are  developed  with  many 
unique  components,  and  (c) 
are  procured  as  commodities 
for  integration  into  larger  sys¬ 
tems.  Under  such  conditions, 
creation  of  well-integrated 
ships  demands  a  major  inte¬ 
gration  effort.  We  have  been 
able  to  make  some  progress  by 
working  hard  to  overcome  the 
barriers.  But  success  remains 
elusive,  and  the  downsizing 
now  in  progress  threatens  our 
ability  to  execute  this  approach 
in  the  future. 

The  alternative  is  to  build  systems  that  work  to¬ 
gether  by  design,  so  that  the  ship  as  a  whole  be¬ 
comes  a  “system  of  systems.”  This  can  be  achieved 
by  creating,  between  the  ship  level  and  that  of  indi¬ 
vidual  systems,  some  kind  of  framework  for  team¬ 
work  in  development  of  the  individual  systems.  The 
top-level  partitioning  of  control  functions  for  the  ship 
is  seen  as  a  key  factor.  The  core  problem  is  not  how 
to  break  a  ship  into  individual  systems,  but  how  the 


HM&E 

Systems 


Services  & 
Logistics 
Support 


Combat 

Systems 


Embarked 

Vehicles 


ACQUISITION  STOVEPIPES 

“System  of  Systems” 


•  Teamwork 

•  Total  Ship 

•  Backbone 
Architecture 


The  Navy  is  faced  with  a  number  of  challenges 
to  its  total  ship  system  engineering  capability.  As 
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systems  can  be  made  to  work  together  as  parts  of  a 
unified  whole  (total  ship).  Our  approach  to  partition¬ 
ing,  outlined  on  page  7,  creates  three  backbone  el¬ 
ements  (combat  control,  plant  control,  and  informa¬ 
tion  management)  to  foster  integration.  The  first  two 
involve  some  change  in  the  traditional  partitioning 
of  combat  systems  from  hull,  mechanical,  and  elec¬ 
trical  systems.  The  last  recognizes  that  information 
is  a  resource  demanding  coordination  on  a  shipwide 
basis  and  that  special  attention  may  be  needed  to 
create  the  necessary  means  for  coordination. 

Acquisition  Process  Improvement 

The  third  major  element  of  the  reinvention 
strategy  has  been  to  foster  a  disciplined  system 
engineering  approach  in  which  affordability  and 
capability  are  considered  as  two  sides  of  the  same 
coin  (i.e.,  a  strong  fleet).  The  aim  is  to  achieve  major 
gains  in  affordability  without  sacrificing  needed 
capability.  This  can  be  done  by  reinventing  the  total 
ship  system  engineering  enterprise  to  improve 
productivity  across  the  board.  The  pie  chart  from 
Reference  1  shown  here  applies  to  life  cycle  cost  for 
a  typical  naval  ship.  The  relative  size  of  the  pieces 
will  differ  for  any  particular  design.  The  largest  piece 
shown,  personnel  cost,  can  be  addressed  by 
automation  and  by  process  reengineering.  While 
the  original  data  applies  to  the  ship’s  crew,  ashore 
personnel  costs  must  also  be  recognized  as  a 
contributor.  Other  areas  can  be  addressed  by 


LIFE  CYCLE  COSTS 


exploiting  commercial  products  and  by  reinventing 
development  and  support  processes.  There  is  also 
potential  for  broad  gains  through  improved 
productivity  in  shipbuilding  and  construction. 

What  We  Are  Doing 

A  number  of  things  are  being  done  to  pursue 
the  goals  articulated  by  “the  Gang.”  Reference  2  lays 
foundations  for  a  total  ship  system  engineering  pro¬ 
cess  and  highlights  the  idea  of  a  common  back¬ 
bone  for  combat  control.  A  workshop  held  last  fall 
made  useful  contributions  to  definition  of  the  remain¬ 
ing  backbone  elements,  in  plant  control  and  readi¬ 
ness  and  in  information  management;  Reference  3 
gives  results.  The  workshop  addressed 
reengineering  ideas  for  selected  mission  teams  and 
tasks.  Reference  4  expands  on  the  backbone  con¬ 
cept  featured  in  the  earlier  reports. 
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EXPLORING  THE  CONCEPT 


While  several  reports  have  been  written,  the  main 
value  of  the  effort  is  not  in  reports  but  in  drawing 
different  parts  of  the  surface  ship  community  into  a 
dialog  on  total  ship  system  engineering  practices. 
A  process  for  coordinated  efforts  to  identify  agreed- 
to  design  concepts  or  target  architectures,  standards, 
and  engineering  tools  would  mean  a  big  step  for¬ 
ward.  Consensus  guidelines  could  be  used  by  ma¬ 
jor  programs  to  ensure  their  products  fit  into  the  tar¬ 
get  ship  design  and  can  be  used  in  other  classes  as 
well. 
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TRADITIONAL  SHIP  ENGINEERING  PROCESS 


History 

As  the  figure  below  suggests,  the  Navy  has  ex¬ 
perimented  with  many  different  approaches  to  ship 
design.  Stovepiping  and  the  increasing  complexity 
of  modern  systems  have  been  constant  concerns 
throughout  this  period.  In  the  1950s,  design  func¬ 
tions  were  largely  performed  in  house.  The  Bureau 
of  Ships  (BuShips)  had  separate  organizations  for 
preliminary  design  and  contract  design.  There  was 
some  in-house  construction  at  naval  shipyards.  In 
the  1 960s,  the  concept  of  total  package  procurement 
shifted  design  of  several  major  ship  classes  to  the 
private  sector.  Use  of  public  shipyards  for  new  con¬ 
struction  was  eliminated. 


•  Defense  Acquisition  Reform 

(CHENG  D/A/C  Project)  -  90s 

•  Ship  Procurement  Process 

Study  (Competition)  -  80s 

•  Design  to  Cost  -  70s 

•Total  Package  Procurement  -  60s 

•  BuShips  Reorganization  -  50s 


THEMES  SINCE  1950 


In  the  1970s,  there 
was  a  return  to  in- 
house  ship  design 
with  a  central  design 
management  organi¬ 
zation  in  the  Naval 
Ship  Engineering 
Center  (NAVSEC). 
However,  the  design- 
to-cost  philosophy 
was  practiced  for 
much  of  the  decade. 
The  growing  Soviet 
naval  threat  became  a 
dominant  theme  in  the 
mid-1970s,  causing  a 
great  deal  of  attention 


to  be  paid  to  concepts  and  methods  of  ship  design 
and  engineering. 

Acquisition  streamlining  became  a  major  theme 
in  the  1980s,  with  increased  shipbuilder  participa¬ 
tion  in  the  design  process.  This  trend  has  continued 
into  the  present,  with  Defense  Acquisition  Reform 
and  commercialization  emerging  as  major  themes. 

Baseline  Process 

The  sequence  of  events  shown  applies  in  a  gen¬ 
eral  way  to  naval  ship  design  since  1970.  For  many 
years,  the  overall  strategy  for  ship  design,  construc¬ 
tion,  and  support  has  been  dominated  by  a  bottom- 
up  approach  to  design  and  development.  Ship  de¬ 
signers  choose  the  hull  form  and  propulsion  machin¬ 
ery  for  desired  maneuvering  and  seakeeping  quali¬ 
ties,  while  ship  size  and  arrangement  are  varied  to 
meet  demands  for  space,  weight,  aperture,  and  sta¬ 
bility  driven  by  the  required  payload  systems.  The 
basic  concept  is  to  deal  with  problem  complexity  by 
dividing  component  development  responsibilities 
among  a  loosely  coordinated  array  of  programs. 
Each  program  office  builds  a  little,  tests  a  little,  speci¬ 
fies,  and  finally  produces  a  stand-alone  system. 

The  ship  is  then  constructed  by  a  process  of 
component  assembly  and  integration,  proceeding 


BASELINE  ACQUISITION  PROCESS 
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from  the  keel  up.  Ship  designers  have  traditionally 
acted  as  physical  integration  agents,  defining  the  hull, 
mechanical,  and  electrical  interfaces  necessary  to 
package  the  stand-alone  systems  into  the  hull.  In 
this  context  total  ship  engineering  means  ensuring 
that  appropriate  ship  elements  are  selected  and  ef¬ 
fectively  and  efficiently  combined  to  satisfy  opera¬ 
tional  requirements  and  design  constraints. 

While  this  approach  yields  warships  that  work,  it 
is  costly  in  terms  of  acquisition,  manning,  and  logis¬ 
tics  support  and  has  made  it  difficult  to  achieve  a 
highly  integrated  control  structure.  Today  comput¬ 
ing  capacity  is  virtually  unlimited,  freeing  the  designer 
to  engineer  the  ship  as  a  system  of  systems.  Quali¬ 
ties  of  firepower,  stealth,  interoperability,  and 
affordability  needed  in  future  warships  make  a  top- 
down,  integrated  design  process  imperative. 

Underlying  Concept  Of  Ship  Development 

Despite  the  many  twists  and  turns  in  acquisition 
policy,  the  core  process  shown  below  seems  to  have 
been  fairly  stable  over  time.  To  begin,  the  strategy 
is  one  of  centralized  planning  and  decentralized  ex¬ 
ecution.  The  Office  of  the  Chief  of  Naval  Operations 
(OPNAV)  plans  the  force  and  the  Naval  Sea  Sys¬ 
tems  Command  (NAVSEA)  executes  the  programs. 
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CORE  PROCESS 


Ships  are  designed  by  a  central  engineering  staff, 
with  detailed  design  and  construction  contracted  to 
a  shipyard. 

The  core  process  resembles  the  “command  and 
control”  scheme  pioneered  by  General  Motors  to 
produce  a  car  for  “every  purse  and  purpose.”  Many 
ship  types  are  produced,  each  with  different  mis¬ 
sion-critical  systems  but  many  common  components 
as  well.  Where  possible,  common  designs  may  be 
used  across  the  entire  Fleet.  A  typical  ship  has 
scores  of  individual  systems,  each  with  a  specific 
purpose,  and  thousands  of  functionally  complete 
components.  Scores  of  acquisition  programs  and 
thousands  of  suppliers  are  involved  in  creating  com¬ 
ponents  and  delivering  them  to  the  shipyard.  In  the 
reference  process,  the  central  engineering  staff  de¬ 
signs  the  parts  and  gives  the  drawings  to  suppliers 
for  bid.  Some  of  the  suppliers  are  in-house  activi¬ 
ties,  and  bureaucracy  is  a  factor  in  dealing  with  them. 
Price  is  the  main  factor  in  dealing  with  external  sup¬ 
pliers,  and  the  process  is  vulnerable  to  buy-in. 


Centralized  Planning  & 
Decentralized  Execution 


In-House  Team  Leader 

•  Control  Design  Process 

•  Collocated  Design  Team 

•  Converging  Programs 

•  Built-in  Stovepipe  Effects 


Many  External  Suppliers 

•  Detail  Design  &  Construction 

•  Many  Individual  Systems 

•  Integration  After  the  Fact 

•  Vulnerable  to  “Buy-in" 


MAIN  FEATURES  OF  REFERENCE  PROCESS 

The  reference  process  is  intended  for  in-house 
execution,  and  where  used  by  industry,  roughly  30 
percent  of  total  value  may  be  produced  by  outside 
suppliers.  This  includes  bulk  materials  and  commodi¬ 
ties  (such  as  fasteners)  that  are  widely  available.  In 
naval  construction,  teams  of  internal  and  external 
suppliers  are  used  for  each  system  and  ship,  so  the 
in-house  value  added  is  comparatively  low. 

The  next  section  describes  an  alternate  ap¬ 
proach  that  can  be  pursued  to  achieve  desired  out¬ 
comes. 
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TOTAL  SHIP  SYSTEM  ENGINEERING  APPROACH 


Point  Of  Departure 

Regardless  of  the  approach  to  spatial  arrange¬ 
ment  and  physical  modularity,  a  control  structure  is 
necessary  to  make  the  ship  responsive  to  command 
direction  and  control.  In  defining  a  framework  for 
dealing  with  command  and  control  functions  on  a 
total  ship  basis,  we  start  with  a  simple  view  of  the 
ship  as  shown  below. 


SIMPLIFIED  VIEW 

People  are  shown  at  the  top,  organized  into 
mission  teams.  Only  by  the  direction  of  its  crew  does 
the  ship  become  a  complete  warfighting  system, 
capable  of  acting  on  its  own  to  some  degree.  Even 
a  fully  automated  ship  would  execute  broad  plans 
and  orders  only  in  accordance  with  direction  from  a 
mission  team  located  elsewhere.  The  mission  teams 
are  supported  by  various  categories  of  physical 
resources  (radars,  ship  machinery,  missiles,  etc.), 
accessed  via  control  interfaces.  What  is  being 
addressed  in  the  system  of  systems  framework  is 
the  process  by  which  the  control  interfaces  are 
engineered.  An  expanded  view  appears  in  the  next 
figure. 


be  driven  first  and  foremost  by  operational  consid¬ 
erations.  Another  important  principle  is  that  engi¬ 
neering  work  units  should  be  organized  on  the  par¬ 
titioning  thus  determined.  The  control  structure  thus 
reflects  two  key  viewpoints.  The  first  must  be  a 
warfighter’s  view,  considering  the  essential  military 
purpose  of  the  ship.  The  second  is  that  of  the  devel¬ 
opment  organization  responsible  for  ship  design,  ac¬ 
quisition,  construction,  and  support. 

Mission  Operations 

The  operational  viewpoint  is  considered  first.  The 
center  section  of  the  previous  figure  is  here  ex¬ 
panded  a  bit  to  show  the  basic  structure  of  the  con¬ 
trol  interface  functions.  How  the  control  structure  is 
partitioned,  and  how  the  parts  interact,  is  the  key  to 
total  ship  integration. 

Combat  control  (mission  operations)  and  plant 
control  involve  a  rearrangement  of  the  traditional 
partitioning  of  combat  systems  from  hull,  mechanical, 
and  electrical  systems.  However,  in  future  ships  the 
position  of  this  boundary  may  change.  Maneuver 
control  and  damage  control  coordination  are  areas 
that  may  move  across  the  boundary.  Information 
management,  the  third  element  of  the  partitioning, 
recognizes  that  information  demands  coordination 
on  a  shipwide  basis  and  that  special  attention  may 
be  necessary  to  create  suitable  means  of 
coordination. 

The  three  major  elements  we  refer  to  as  control 
backbones.  Some  of  the  major  functions  to  be  con¬ 
trolled  in  each  are  shown  in  the  figure.  As  a  system 
of  systems,  the  ship  provides  mission  teams  in  each 
area  with  the  resources  to  perform  all  assigned  tasks, 
together  with  the  interfaces  and  interconnections  that 
make  them  responsive  to  human  direction  and  con¬ 
trol.  For  ships  that  are  not  combatants,  the  term 
Mission  Operations  can  be  used  in  place  of  Combat 
Control.  With  this  convention,  the  partitioning  shown 
is  applicable  to  all  ship  types. 


The  strategy  for  partitioning  control  resources  System  of  Systems 
on  a  total  ship  basis  is  rooted  in  basic  principles  of 

system  engineering.  The  first  principle  is  that  the  As  indicated  earlier,  the  missing  factor  in  today’s 
aim  of  design  must  be  to  help  the  warfighters  in  approach  to  total  ship  system  engineering  is  a  frame- 
achieving  their  operational  objectives.  The  implica-  work  for  dealing  with  the  ship  as  a  system  of  sys- 
tion  is  that  a  partitioning  for  total  ship  design  must  terns.  What  is  lacking,  in  other  words,  is  a  way  of 
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Mission  Teams 
and  Tasks 


•  Operating  Concept 

•  Command  Structure 

•  Ops  Environment 


Plant 

Control 


Individual 

Systems 


•  Hull,  Machinery,  Elex 

•  Combat  Systems 

•  C4I  Resources 


Information 

Management 


Sensing 
Computing 
Planning  Support 


— 


Maneuver 
Interoperate 
Fight  , 


Mission 

Operations 


Float 

Move 

Accommodate  People 
Provide  Services 
Manage  Readiness 


such  a  framework. 
One  level  provides  co¬ 
ordination  for  the  over¬ 
all  system,  working 
across  projects,  while 
the  other  manages  in¬ 
dividual  projects.  Es¬ 
tablishment  of  this 
framework  begins  with 
domain  analysis,  to  es¬ 
tablish  a  common  foun¬ 
dation  for  specifying 
system  concepts  and 
requirements.  Next,  in¬ 
frastructure  and  inte¬ 
gration  architecture  are 
used  to  enable  integra¬ 
tion  of  component  sys¬ 
tems  into  a  consistent 
overall  system  in  an  ef¬ 
ficient  way. 


LAYERED  CONCEPT  FOR  TOTAL  SHIP  “SYSTEM  OF  SYSTEMS” 


defining  and  controlling  the  system  engineering  pro¬ 
cess  across  the  entire  set  of  independently  designed 
and  procured  components  to  meet  the  requirements 
for  a  surface  combatant.  Some  things  this  frame¬ 
work  should  strive  for  include  (1)  a  fully  integrated 
control  structure,  (2)  ability  to  share  system  re¬ 
sources  as  necessary  to  coordinate  and  support 
subsystems,  and  (3)  the 
ability  to  change  and  up¬ 
grade  components  easily. 

For  a  large  composite 
system  such  as  a  ship, 
dealing  with  component 
systems  one  by  one  is  not 
good  enough.  A  better 
approach  is  needed,  one 
that  permits  coordination 
of  many  independent 
projects  to  create  a  fully 
integrated  system  of  sys¬ 
tems.  Use  of  a  generic 
framework,  dividing  the 
effort  into  several  projects 
and  two  levels  of  manage¬ 
ment,  is  suggested.  The 
following  figure  shows 


System  of  systems 
engineering  involves 
two  kinds  of  integration,  one  that  focuses  on  mecha¬ 
nisms  used  to  interconnect  parts  and  another  that 
focuses  on  the  coherence  of  an  overall  system  de¬ 
sign.  A  dictionary  definition  of  the  term  integration 
(make  whole  or  complete  by  bringing  together  parts) 
succinctly  captures  this  tension  between  the  parts 


TWO-LEVEL  FRAMEWORK 
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and  the  whole.  On  the  one  hand,  we  talk  about  a 
system,  a  whole  or  complete  thing;  on  the  other,  we 
talk  about  bringing  together  parts.  The  system  side 
of  the  equation  emphasizes  global  system  proper¬ 
ties,  such  as  a  harmonious  “look  and  feel”  in  user 
interfaces,  or  the  linguistic  elegance  of  system  struc¬ 
ture.  The  parts  side  of  the  equation  emphasizes  in¬ 
terconnection  and  interoperation  (e.g.,  of  functions, 
data  files,  and  subsystems). 

Sequence  of  Design  Decisions 

The  core  of  the  system  engineering  problem  is 
not  how  to  decompose  the  overall  system  into  sub¬ 
systems  but  how  to  integrate  subsystems  into  an 
overall  solution.  The  challenge  is  to  decompose 
tasks  and  to  allocate  subtasks  without  compromis¬ 
ing  the  wholeness  of  the  task.  When  the  problem  is 
viewed  from  this  perspective,  it  is  clear  that  a  sys¬ 
tem  engineering  process  involves  a  set  of  interact¬ 
ing  or  interdependent  subproblems.  The  sequence 
for  addressing  the  subproblems,  together  with  the 
solution  strategies  employed,  becomes  a  specifica¬ 
tion  for  the  process. 


Because  the  development  team  must  deal  with 
acquisition  and  integration  of  individual  systems  as 
well  as  overall  ship  construction,  its  organization  is 
a  bit  more  complicated  than  the  operational  control 
structure.  Once  an  adequate  understanding  of  mis¬ 
sion  teams  and  tasks  has  been  created,  the  devel¬ 
opment  team  must  address  overall  ship  design,  de¬ 
sign  of  backbone  control  structures,  and  definition 
of  specific  operating  processes  adequate  to  meet 
mission  needs.  Each  of  the  corresponding  activi¬ 
ties  makes  a  key  contribution  to  creation  of  a  total 
ship  system  of  systems  from  the  variety  of  individual 
systems  delivered  by  suppliers. 

The  ship  design  activity  provides  the  engineer¬ 
ing  studies  necessary  to  address  the  questions  of 
ship  form,  size,  and  essential  military  characteris¬ 
tics.  Speed,  seakeeping,  strength,  stability,  and  style 
are  the  major  naval  architecture  issues.  These  char¬ 
acteristics  are  all  interrelated  and  dependent  on  over¬ 
all  ship  configuration  and  dimensions.  Accordingly, 
this  activity  controls  the  ship  design  budgeting  pro¬ 


SEQUENCE  OF  DESIGN  DECISIONS 


Although  problem 
solving  may  follow  a  spi¬ 
raling  and  iterative  trajec¬ 
tory  through  the  different 
sets  of  subproblems,  the 
solution  at  any  stage  can¬ 
not  be  finalized  until  solu¬ 
tions  are  reasonably  well 
worked  out  for  previous 
stages. 

Teamwork  In 
Acquisition 


The  development 
enterprise  must  be 
structured  to  maximize 
value  delivered  to  mission 
teams  on  a  life  cycle  basis. 

This  drives  the  role  of  the 
development  team  leader, 
who  must  be  concerned 
with  the  enterprise  as  a  whole,  working  to  shape 
the  value  stream  to  maximize  value  delivered.  Core 
concerns  of  the  lead  activity  are  highlighted  in  the 
next  figure,  which  represents  a  layered  concept  for 
organization  of  a  total  ship  system  engineering 
enterprise. 


cess,  including  signature  and  survivability,  in  addi¬ 
tion  to  weight,  space,  moment,  and  cost  factors.  It 
also  provides  the  physical  interfaces  (spatial,  me¬ 
chanical,  and  electrical)  necessary  for  the  many  in¬ 
dividual  systems  packaged  into  a  multimission  ship. 
Virtually  all  the  resulting  information  finds  its  way 
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Mission  Teams 
and  Tasks 


’  Operating  Concept 

>  Command  Structure 

>  Ops  Environment 


Ship  Design 


Hull  &  Machinery 
Arrangements 
Trade-Off 
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Backbones 


Mission  Operations 
Plant  &  Readiness 
Info  Management 


Operating 

Processes 


Definition 

Simulation 

Assessment 


O 


O 


Individual 

Systems 


•  Hull,  Machinery,  Elex 

•  Combat  Systems 

•  C4I  Resources 


ORGANIZING  FOR  TOTAL  SHIP  SYSTEM  ENGINEERING 


into  the  drawings  and  specifications  used  by  the 
shipbuilder. 

The  backbone  design  activity  provides  for  inte¬ 
gration  of  all  on-board  control  resources,  in  effect 
making  the  ship  a  real  “system  of  systems.”  Ships 
are  composed  of  many  individual  systems.  The  con¬ 
trol  structure  must  include  mechanisms  to  facilitate 
cooperation  among  them,  without  compromising 
their  ability  to  perform  mission  tasks.  Just  as  do¬ 
main  models  permit  a  common  understanding  of 
goals  and  requirements  at  the  level  of  individual  sys¬ 
tems,  the  backbones  permit  a  shared  understand¬ 
ing  of  how  control  functions  and  interfaces  will  be 
handled.  Their  creation  will  establish  a  standard  for 
services  available  to  individual  systems,  and  pro¬ 
vide  guidelines  for  the  design  of  control  structures 
and  interfaces  by  individual  projects. 

An  activity  responsible  for  process  evaluation  and 
integration  is  also  necessary.  The  basic  purpose  of 
this  activity  is  to  understand  what  mission  teams 
must  do  and  how  well  the  ship,  as  a  system  of  sys¬ 
tems,  can  create  and  coordinate  action  paths  ad¬ 
equate  to  meet  operational  needs.  This  calls  for  a 
total  ship  perspective  together  with  a  capability  for 
detailed  analysis  of  ship  characteristics  and  perfor¬ 
mance. 


Seeking  An  Integrated  Value 
Stream 

The  effort  to  reinvent  surface 
combatants  doesn’t  stop  with  a 
new  emphasis  on  mission  teams 
and  the  system  of  systems  inte¬ 
gration  framework.  The  Navy  can 
also  reinvent  how  it  organizes  for 
design,  construction,  and  support 
of  future  surface  combatants.  Cur¬ 
rent  acquisition  reform  concepts, 
including  the  use  of  integrated 
product  and  process  development 
methods,  are  based  on  this  theme. 

In  fact,  industry  has  turned 
reinventing  the  enterprise  into 
something  of  a  global  trend.  For 
the  most  successful  efforts,  think¬ 
ing  in  terms  of  a  value  stream  has 
been  the  first  step.  The  enterprise 
is  defined  not  as  a  single  activity 
but  a  group  of  activities  working  to¬ 
gether  to  supply  a  good  or  service 
in  a  way  that  creates  maximum  value  for  the  cus¬ 
tomer  (in  our  case  the  warfighter  or  mission  teams). 
This  drives  the  role  of  the  enterprise  leader,  who 
must  act  to  shape  the  overall  value  stream  and  not 
value  added  by  direct  individual  effort  alone.  This 
causes  a  shift  away  from  stovepipe  thinking  to  glo¬ 
bal  or  team  thinking.  In  particular,  greater  attention 
is  given  to  relationships  among  team  members,  and 
to  the  transactions  between  them  that  often  have 
the  most  potential  for  effectiveness  and  productivity 
gains.  The  figure  indicates  how  such  an  enterprise 
might  be  structured. 

This  approach  is  widely  viewed  as  an  improved 
model  for  design  of  large  products  systems.  The 
original  implementation  is  credited  to  EijiToyoda  and 
Taiichi  Ohno  and  is  sometimes  called  the  Toyota 
Production  System.5  The  basic  aim  was  to  form  a 
vast  group  of  suppliers  and  parts  plants  into  a  single 
“machine”  by  producing  at  each  step  only  those  parts 
necessary  to  satisfy  immediate  demand  at  the  next 
step.  The  final  assembly  organization  functions  as 
the  enterprise  leader.  Usually,  design  and  produc¬ 
tion  of  components  that  tend  to  define  product  style 
and  performance  (the  product’s  “signature”)  are  per¬ 
formed  in  house.  Thus  the  enterprise  maintains 
control  of  the  product  line,  but  the  value  added  by 
in-house  divisions  may  be  as  little  as  25  percent  of 
the  total. 
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Suppliers  are  organized  into  functional  tiers,  with 
multiple  products  and  multiple  sources  in  each  tier. 
First-tier  suppliers  have  an  integral  role  in  product 
development  and  are  assigned  a  whole  component 
to  design.  The  suppliers  work  to  a  performance 
specification  for  a  system  that  must  work  in  harmony 
with  other  components,  from  other  suppliers.  Toyota 
formed  first-tier  companies  by  spinning  off  in-house 
divisions  and  building  long-term  alliances  with  ex¬ 
ternal  suppliers.  Production  is  typically  shared 
among  several  sources,  with  shares  fluctuating  up 
or  down  according  to  performance. 


VALUE  DELIVERY  ENTERPRISE 


Second-tier  suppliers  tend  to  specialize  in  a 
manufacturing  process.  A  first-tier  supplier  might 
design  an  alternator,  for  example,  and  buy  all  parts 
from  second-tier  suppliers.  The  latter  have  no  role 
in  overall  product  design  but  may  produce  drawings 
for  individual  parts  and  have  firms  at  still  lower  tiers 
produce  parts  to  those  drawings.  Since  companies 
at  level  2  generally  do  not  compete  for  specific  com¬ 
ponent  types,  they  can  work  together  in  supplier 


associations  for  the  purpose  of  sharing  information 
on  manufacturing  techniques. 

The  concept  of  operation  is  based  on  mutually 
agreed  pricing,  strong  incentives  for  performance 
and  sharing  of  information,  and  long-term  relation¬ 
ships.  Direct  competition  for  production  work  be¬ 
tween  in-house  and  external  activities  is  avoided, 
as  it  tends  to  be  inefficient  and  unfair. 

For  surface  ships,  maximizing  value  delivered 
to  mission  teams  on  a  life  cycle  basis  would  become 
the  basis  for  organization.  The  enterprise  leader  is 
viewed  as  an  integrated  product  team  (IPT)  with  both 
Navy  and  builder  elements.  Core  concerns  of  the 
leader  are  mission  teams  and  tasks,  overall  ship 
design,  backbone  control  structures,  and  definition 
of  operational  processes,  as  shown  on  Page  1 0.  In 
short,  the  enterprise  leader  controls  the  overall  de¬ 
sign  process,  including  weight,  space,  and  cost  bud¬ 
gets;  the  strategy  for  integration  and  control  of  mis¬ 
sion  capability;  and  creation  of  the  mission-critical 
capabilities  that  are  the  reason  for  taking  the  ship  to 
sea. 

Beyond  this,  we  believe  the  Navy  should  rethink 
the  entire  chain  of  supply,  adopting  the  best  prac¬ 
tices  from  major  enterprises  around  the  world.  At 
each  tier,  supplier  associations  can  be  formed  to 
create  open  specifications  and  standards;  process 
improvement  techniques  can  also  be  shared.  Sup¬ 
pliers  in  the  first  tier  (major  systems)  should  partici¬ 
pate  in  overall  ship  design.  Lower-tier  suppliers 


Establishing  User  Needs 

•  What  Must  Warfighters  Do? 

•  Role  of  Surface  Ships 

Role  of  Team  Leader 

•  Vision  of  Total  Value  Stream 

•  Design  &  Budgeting  Process 

•  Integration  Strategy 

•  Mission-Critical  Systems 

Rethink  Chain  of  Supply 

•  Multiple  Streams  &  Sources 

•  Performance  Incentives 

•  Open  Specs  &  Standards 

•  Long-Term  Relationships 


IMPLEMENTATION  DRIVERS 


11 


TSSE  APPROACH 


should  be  able  to  participate  in  both  commercial  and 
defense  markets.  Ideally,  Navy  R&D  results  would 
be  shared  as  much  as  possible  among  same-tier 
activities. 

Teamwork  Environment 

Teamwork  is  one  of  the  key  characteristics 
sought  in  the  target  total  ship  engineering  process. 
This  calls  for  use  of  a  systems-of-systems  engineer¬ 
ing  approach  and  reliance  on  shared  concepts,  stan¬ 
dards,  and  tools  to  promote  design  integration.  The 
first  and  most  important  step  is  probably  to  form  a 
cadre  able  to  consider  trade-offs  from  a  total  ship 
perspective.  At  the  same  time,  full  appreciation  for 
(and  access  to)  the  specialized  technical  knowledge 
of  functional  activities  remains  essential.  Teamwork 
is  very  difficult  because  the  problem  is  very  com¬ 
plex.  By  fostering  a  shared  understanding  of  the 
problem  and  adopting  a  common  language,  cadres 
can  learn  to  work  effectively  together  from  different 
locations,  as  long  as  frequent  communication  is  per¬ 
mitted. 


COMPOSITE  PRODUCT 


•  Low  Automation  in  Design 

•  Voice-Based  Info  Sharing 

•  Site-Limited  Interactions 

•  One  Product  -  Many  Visions 


COLLOCATED  TEAM 


The  idea  of  using  computer  networks  for  team¬ 
work  is  no  longer  a  new  one.  Today  it  is  possible  to 
think  of  a  team  being  brought  together  on  the  net¬ 
work,  sharing  information  and  holding  meetings  en¬ 
tirely  via  the  network,  using  common  design  aids 
and  groupware.  A  virtual  team  is  an  integrated  prod¬ 
uct  team  consisting  of  members  with  different  per¬ 
spectives  on  product  development,  wielding  power¬ 
ful  computer-aided  engineering  (CAE)  tools  in  their 
individual  work  spaces  but  publishing  results  to  a 
shared  information  base.  An  overarching  coordina¬ 
tion  service  may  also  exist  to  schedule  work,  report 
progress,  notify  persons,  authorize  work,  and  carry 
out  entire  suites  of  coordinated  processes  without 
the  need  for  face-to-face  meetings. 


War  Fighters  Support 

•  Computer  Aided  Engineering 

•  Network-Based  Info  Sharing 

•  Multiple  Sites  Interconnected 

•  One  Vision,  FuHy  Integrated  Team 


VIRTUAL  TEAM  APPROACH 

The  next  section  considers  what  opportunities 
exist  currently  for  pursuing  the  broad  actions  identi¬ 
fied  in  this  section.  It  is  essential  to  recognize  that 
ship  development  tends  to  be  evolutionary  in  char¬ 
acter.  Ships  are  so  complex  that  it  is  difficult  to  cre¬ 
ate  entirely  new  combatants  with  no  use  of  legacy 
systems. 
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VISION  AND  OPPORTUNITIES 


Begin  With  Mission  Teams 

As  indicated  earlier,  mission  teams  and  tasks 
are  the  starting  point  for  the  total  ship  system  engi¬ 
neering  process.  A  key  goal  for  process  improve¬ 
ment  is  to  strengthen  the  sense  of  partnership  be¬ 
tween  mission  teams  and  the  development  and  sup¬ 
port  teams  that  exist  to  provide  them  with  resources. 
Primary  emphasis  here  is  on  understanding  what 
the  mission  teams  must  do  and  engineering  sys¬ 
tems  to  support  or  execute  those  tasks  efficiently. 
Future  ships  will  fight  by  wire!  The  control  back¬ 
bones  interface  the  warfighter  with  the  weapons, 
sensors,  and  other  resources  used  to  cany  out  the 
mission.  The  backbones  determine  not  only  the  “look 
and  feel”  of  the  ship  to  the  warfighter  but  have  em¬ 
bedded  in  them  how  the  ship  will  be  fought  in  terms 
of  processes  and  procedures.  It  is  thus  imperative 
to  have  the  warfighter  involved  in  the  design  pro¬ 
cess.  Designers  must  listen  to  the  “voice  of  the 
warfighter,”  the  customer. 

Vision  For  Command  Spaces 

Littoral  warfare  operations  seem  likely  to  demand 
increased  flexibility  in  surface  ship  command  and 
control  capabilities.  For  example,  a  future  combat¬ 
ant  might  be  organized  to  deal  with  power  projec¬ 
tion,  battle  space  dominance,  information  warfare, 
survivability,  and  mobility  as  the  major  operational 
tasks  to  be  performed.  In  addition,  various  special- 
purpose  teams,  such  as  a  joint  air  identification  team 
or  a  Marine  Corps  air  defense  control  team,  might 
have  to  be  supported.  It  could  also  be  necessary  to 
adapt  to  changes  in  the  joint  command  structure  as 
a  conflict  situation  evolves.  Indeed,  each  forward 
deployment  cycle  might  call  for  a  different  command 
structure,  or  variation  from  some  core  structure. 
Reconfigurable  and  flexible  command  spaces  are 
then  important,  permitting  adaptation  to  specific  mis¬ 
sion  needs  through  rearrangement  of  mission  teams 
and  watch  stations.  System  engineering  methods 
must  be  formulated  to  identify  designs  that  are  open 
and  adaptable  to  emerging  needs  and  to  provide 
decision  aids  for  tailoring  a  ship’s  command  struc¬ 
ture  to  specific  mission  needs. 

Future  command  spaces  should  be  designed  as 
open  systems  to  enable  easy  upgrades  as  well  as 
operational  flexibility.  The  initial  design  should  be 
viewed  as  the  nucleus  of  a  more  advanced  or  larger 


ADAPTABLE  COMMAND  SFACES 


system,  with  hooks  installed  to  support  change.  As 
indicated  in  the  box  below,  a  wide  range  of  new  sys¬ 
tems  and  technologies  are  likely  to  appear  in  com¬ 
mand  spaces  over  the  next  few  decades.  In  time, 
major  changes  are  likely  in  how  military  forces  orga¬ 
nize  to  use  information.  This  could  mean  collabora¬ 
tive  work  styles  instead  of  hierarchies,  in  which  bottle¬ 
necking  limits  flexibility.  Future  systems  may  use 
network  structures  extending  across  the  life  lines. 
Another  key  source  of  change  is  automation,  which 
can  alter  task  allocation  between  humans  and  ma¬ 
chines.  To  prepare  the  way  for  change,  it  is  impor¬ 
tant  to  establish  a  disciplined  process  for  managing 
life  cycle  cost  and  system  integrity. 


■^APPLICATIONS 

•  Distributed  Command  Systems 

•  Wide  Area  Surveillance  Displays 

•  Integrated  Command  Support 

•  Novel  Layout  (e  g.,  Sensurround) 

^TECHNOLOGIES 

•  Teleconference  Capability 

•  Interactive  and  3D  Displays 

•  Virtual  Reality  in  Planning 

•  Enhanced  Operator  Interfaces 

•  Automation  to  Reduce  Manning 


TRENDS  IN  COMMAND  SFACES 
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Technology  Opportunities 

Future  watch  stations  will  provide  better  displays, 
new  ways  for  people  to  interact  with  computers,  and 
better  ways  to  aid  decision  making.  Opportunities 
include  the  following. 

•  Human  -  Computer  Interfaces.  How  operators 
interact  with  displays  can  be  much  better  than 
today’s  hook,  ball  tab,  and  cursor  technique.  In¬ 
teractive  device  technology  will  permit  the  use  of 
voice  recognition,  interactive  screens,  and  a  vari¬ 
ety  of  pointing  techniques  in  future  display  inter¬ 
faces. 

Pointing  techniques  will  include  eye-safe  laser 
devices,  photoelectric  light-sensitive  pointing  de¬ 
vices,  mouse  pads,  and  other  devices.  There  are 
existing  prototypes  that  allow  interaction  with  vari¬ 
ous  displays  via  eye  contact.  This  has  been  done  to 
let  pilots  get  information  without  use  of  any  other 
device.  Interactive  (touch-sensitive)  screens  exist 
today  and  improvements  in  granularity  and  sensitiv¬ 
ity  will  continue. 

•  Graphics.  Future  displays  will  use  new  techniques 
to  aid  tactical  operators.  New  symbol  sets  will 
permit  use  of  icons  in  tactical  displays,  leading  to 
reduced  training  time  and  better  retention  of  skills. 


Extensive  use  will  be  made  of  color,  windows, 
icons  and  new  display  heads.  The  latter  may 
include  large  wall  screen,  tabletop,  or  3D  displays. 
Volumetric  (3D)  displays  promise  to  immerse 
decision  makers  in  the  tactical  scene,  where  they 
can  better  use  the  cognitive  skills  underlying 
human  vision  to  grasp  and  utilize  available 
information. 

•  Enhanced  Communications.  This  will  include  the 
use  of  hand-held,  wireless,  intraship  communica¬ 
tions  supported  by  an  automated  locator  service. 

Common  Backbone  For  Combat  Systems 

Based  on  the  total  ship  system  engineering  pro¬ 
cess  and  partitioning  scheme  outlined  in  preceding 
sections,  reengineering  opportunities  have  been  ad¬ 
dressed  for  the  combat  control  area.  The  main  ques¬ 
tion  considered  in  this  pilot  study  was  whether  it 
makes  sense  to  talk  about  a  common  system  engi¬ 
neering  framework  across  many  different  projects 
in  the  combat  system  category.  Results  indicate  a 
common  backbone  structure  may  be  feasible  in  fu¬ 
ture  combat  systems.  The  figure  below  illustrates 
the  concept.  This  would  mean,  for  the  combat  sys¬ 
tem  as  a  whole,  the  kind  of  flexibility  and  resource 
sharing  achieved  by  the  Vertical  Launching  System 

in  handling  multiple  mis¬ 
sile  types  or  by  the  AE¬ 
GIS  Weapon  System  in 
handling  multiple  simulta¬ 
neous  targets. 


The  idea  of  a  com¬ 
mon  operating  environ¬ 
ment  (COE)  is  usually 
applied  only  to  a  comput¬ 
ing  environment.  Creat¬ 
ing  a  common  backbone 
for  combat  control  means 
a  COE  defined  more 
broadly,  to  include  not 
only  processing  re¬ 
sources  but  also  dis¬ 
plays,  watch  stations,  in¬ 
terfaces,  communica¬ 
tions,  and  mission  sup¬ 
port  applications. 


COMBAT  CONTROL  BACKBONE 
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mon  system  services  will  be  provided  to  deal  with 
configuration  management  functions,  such  as  nam¬ 
ing  or  maintaining  a  common  data  element  dictio¬ 
nary.  The  backbone  would  provide  a  standards- 
based  framework  for  development  and  integration 
of  individual  combat  systems.  Individual  system  pro¬ 
grams  would  adopt  a  narrower  focus  on  delivery  of 
mission-unique  applications  and  components.  Use 
of  an  open  system  framework  can  make  a  common 
backbone  approach  both  affordable  and  capable. 
The  potential  benefits  appear  very  significant. 

Vision  For  Ship  Integration 

The  advantages  of  a  common  backbone  apply 
to  all  areas  as  shown  in  the  figure.  What  is  envi¬ 
sioned  is  a  generic  backbone  (with  variants  for  each 
area)  that  supports  design  for  modularity,  common¬ 
ality,  and  the  sharing  of  functional  resources  on  a 
shipwide  basis.  This  modular  framework  must  have 
the  following  attributes: 

•  Command  spaces  become  utilities,  tailorable  to  any 
set  of  mission  teams  and  tasks  required. 

•  Computing,  communication,  and  display  resources 
are  managed  on  a  shipwide  basis,  with  a  common 
application  environment  maintained. 


Mission 

Plant  Control 

Information 

Operations 

(Autonomies) 

Management 

•  Mission  Planning 

*  Paperless  Ship 

•  Tactical  Picture 

*  Battle  Doctrine 

-  Embedded  Training 

•  Unified  Databases 

•  Track  f  Target  Data 

•  Damage  Control 

•  Unified  C2W  Plan 

•  Operator  Interfaces 

•  Machinery  Control 

•  Mapping  Services 

•  Cooperative  Warfare 

•  Condition  Sensing 

• Models  a  Simulation 

•Auto  Uar.euvar 

•  Mission  Modules 

•  Logistics  Support 

MODULAR  FRAMEWORK 


Total  Ship  Target  Architecture:  A  Common 
Operating  Environment 

The  figure  below  represents  the  ship  as  a  lay¬ 
ered  open  system  with  three  entity  types  and  two 
interface  types.  The  target  architecture  represents 
a  strategy  for  applying  the  concept  of  open  systems 
to  warship  development.  The  qualities  of  portability 
and  interoperability  offered  by  open  systems  are 
combined  with  the  reliability  and  effectiveness 
needed  in  combatants. 

The  target  architecture  is  layered  to  form  two 
loosely  coupled  subsystems.  The  first  links  applica¬ 
tion  software  entities  to  application  platform  enti¬ 
ties.  As  in  the  Application  Portability  Profile  defined 
by  NIST  (Reference  6),  the  basic  idea  is  to  make 
the  services  provided  by  the  application  platforms 
(at  their  interfaces)  transparent  to  application 


•  Readiness  and  resources  are 
managed  on  a  shipwide  basis. 


•  Life  cycle  costs  are  reduced  by 
holding  manning  and  parts 
counts  to  minimum  levels,  and 
by  an  open  systems  approach. 


Overall,  the  resulting  archi¬ 
tecture  is  intended  to  be  endur¬ 
ing,  flexible  to  permit  (a)  appli¬ 
cation  to  a  variety  of  ship  types 
and  designs;  (b)  insertion  of  new 
functionality  as  warfighting  sys¬ 
tems  evolve;  and  (c)  insertion  of 
new  technology  as  it  becomes 
available.  The  original  architec¬ 
ture  should  include  an  extension 
framework  and  be  subject  to  for¬ 
mal  change  control  from  the  ear¬ 
liest  stages  of  development. 

TOTAL  SHIP  TARGET  ARCHITECTURE 
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ware.  This  first  subsystem  is  then  loosely  coupled, 
in  that  application  platform  entities  become  inter¬ 
changeable  and  application  software  entities  be¬ 
come  reusable. 

The  second  subsystem  links  external  environ¬ 
ment  entities  to  application  platform  entities.  Again, 
the  basic  idea  is  to  make  services  provided  by  the 
latter  (at  their  interfaces)  transparent  to  individual 
sensors,  weapons,  work  stations,  machinery,  and 
service  systems  throughout  the  ship.  Both  applica¬ 
tion  platform  entities  and  external  environment  enti¬ 
ties  are  viewed  as  providers  of  standard  services, 
and  any  two  elements  providing  equivalent  services 
should  be  interchangeable. 

An  Evolutionary  Strategy 

The  idea  of  a  common  backbone  system  is  prom¬ 
ising,  but  much  remains  to  be  done.  One  of  the  hard 
spots  concerns  the  lack  of  a  working  baseline  with 
open  system  characteristics.  While  reliable  and  ef¬ 
fective,  combat  systems  today  are  hardly  open,  and 
it  is  not  yet  clear  how  to  deal  with  the  problems  of 
weapon  safety  certification  for  open  systems. 

Migrating  to  an  open  system  involves  an  extra 
measure  of  risk  that  is  important  for  both  program 
executives  and  suppliers.  Creating  incentives  for  tak¬ 
ing  the  associated  risks  is  therefore  an  important 
goal.  A  related  problem  is  to  find  ways  to  effectively 
manage  standards-based  backbone  architectures, 
as  standards  evolve  with  time. 

Given  today’s  budget  constraints,  a  transition  to 
common  backbones  probably  won’t  happen  all 
at  once.  However,  the  existing  SC  21  andLPD-17 
programs  offer  a  starting  point.  Progress  made 
toward  a  common  backbone  structure  in  these 
programs  could  be  the  foundation  for  full 
implementation  in  subsequent  ship  design  and 
construction  programs. 

Summary  of  Opportunities 

The  attributes  sought  in  a  total  ship  system 
engineering  process  can  be  listed  as  follows: 

Process  Driven  by  What  the  Warfighters  Must  Do 

•  Continuous  dialog  on  mission  tasks  and  system 
characteristics 

•  Ability  to  tailor  configuration  for  designated  roles 
and  operational  areas 


Common  Backbones  and  Building  Blocks 

•  Same  control  backbones  applicable  to  all  ship 
types 

•  Command  spaces  become  utilities,  useful  for 
any  mission  task 

•  Plug  and  play  flexibility  of  mission  systems, 
data,  resource  flows 

Open  Systems 

•  Portable,  scalable,  reconfigurable,  interoper¬ 
able,  extensible 

•  Easy  upgrades  for  better  performance,  reliabil¬ 
ity,  and  flexibility 

•  Extensive  use  of  commercial  products 

Exploit  Potential  for  Improved  Design  Methods 

•  Simulation-based  design  capabilities 

•  Reengineered  mission  teams  and  operating 
processes 

A  good  deal  of  attention  was  given  to  selection 
of  the  proper  starting  point.  In  the  final  analysis,  we 
believe  that  the  purpose  of  ships  is  to  carry  mission 
teams  to  a  chosen  operating  area  (at  sea).  What 
ships  must  do  depends  on  the  designated  mission 
teams  and  tasks.  System  engineers  must  work  con¬ 
stantly  with  the  warfighters  to  define  the  necessary 
mission  teams  and  tasks,  and  to  engineer  the  oper¬ 
ating  processes  necessary  to  carry  out  those  tasks. 

The  advantages  of  a  common  backbone  apply 
not  only  to  combat  control,  but  to  plant  control  and 
readiness,  and  to  the  area  of  information  manage¬ 
ment  as  well.  What  is  envisioned  is  a  generic  back¬ 
bone  (with  variants  for  each  area)  applicable  across 
ship  types.  Use  of  common  building  blocks  and  open 
systems  would  be  emphasized  on  a  shipwide  basis 
for  all  categories  of  systems  (e.g.,  pumps,  electrical 
systems)  and  not  just  control  structure.  Ships  would 
thus  have  a  minimum  set  of  piece  parts. 

Finally,  new  engineering  methods  and  tools  of¬ 
fer  great  promise  for  improving  the  product  (war¬ 
ships)  and  the  process  of  warship  design,  acquisi¬ 
tion,  and  construction.  Opportunities  in  this  area  are 
especially  important  because  in  a  sense  warship 
design  never  starts  with  a  blank  sheet  of  paper: 
many  components  used  in  construction  are  built  to 
earlier  designs,  and  modernization  during  the  life 
cycle  may  introduce  still  later  designs.  Engineering 
principles  and  methods  embedded  in  design  aids 
will  influence  compatibility  of  designs  from  different 
decades. 
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